The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Developers of computer systems that are intended for use in arbitrary locations in a network, such as servers, workstations, printers and other endpoint hosts, face at least three significant systems-level requirements for external communications: security, performance and management. These requirements are addressed in a set of software components termed a “networking stack” on the endpoint hosts. Relatively secure high-performance open source implementations of networking stacks are provided in BSD-based implementations of the UNIX operating system, such as FreeBSD, OpenBSD, NetBSD. Other implementations of networking stacks are also known and include Linux, HPUX, Microsoft Windows, Sun Solaris and IBM AIX.
Security solutions need to monitor the behavior of network traffic. The evolution of security attacks and countermeasures requires a flexible platform that can be easily extended and even replaced to enable countermeasures to attacks. Achieving both performance and security is practical only with a unified system of network management of the interfaces and their security properties. Network gear vendors and operating system providers are struggling to provide security for bridging behavior in which packets are snooped from one interface and broadcast out another. Vendors also are challenged to control the ability of platforms running multiple operating system (OS) images when one OS image seeks to modify another.
The security applications that rely on access to the networking stack includes virtual private networking, antivirus, inline encryption and message integrity, network discovery, and identity protocols. Each of these applications requires management, especially where they cross boundaries. A unified management interface is practically necessary for these systems to work together.
Concurrently, the growth of communications between computing platforms has led to commensurate growth in the amount of available bandwidth that endpoints need to have, especially in the TCP/IP stack. For example, in recent times endpoints have evolved from needing less than 10 Mbps, to 100 Mbps, to 1 Gbps, and on some endpoint platforms available bandwidth has moved up to 10 Gbps the trend is likely to continue. Such bandwidth growth has led to rapidly increasing burdens on the central processing unit (CPU). Present estimates are that processing communications may involve as much as 70% of total CPU load for TCP/IP at 1 Gbps.
The increase in CPU burden in turn has contributed to the rapid proliferation of dual-processor server machines, which have been developed both to provide enough processor cycles to service application requirements and to provide sufficient cycles for stack-related processing. Although these servers are powerful, they can be complicated to manage because they implement so many computing functions in a single platform. Administrators would benefit from a way to separately manage I/O-networking aspects of high-power servers.
While the problems specifically created by TCP/IP stack processing requirements are noted above, similar problems exist for software stacks that manage other types of interfaces, including peripheral stacks for Fibre Channel, Infiniband, Firewire (IEEE 1394), USB, Bluetooth, wireless 802.11, and other interfaces. The amount of bandwidth utilization for each of these interfaces is increasing. Further, security requirements for inspecting traffic flows and protection over such interfaces are becoming especially significant especially for traffic that bridges from one interface to another.
Past approaches have addressed some of the foregoing problems, either in an incomplete manner or with significant disadvantages. For example, in one approach the growth in bandwidth is accommodated using off-load processors. Off-load processors are special-purpose processors that assume the load that was burdening the main CPU. As an example, off-load processors can be used in TCP offload cards that offload TCP stack processing functions from a set of CPUs for a given interface. Fibre Channel host bus adapter (HBA) cards can offload storage functionality.
However, off-load processors are purpose-specific non-commodity parts, and have had very slow market penetration because of their relatively high cost. Off-load processors are not shared between multiple guest operating systems in a virtualized environment. Off-load processors are not managed from the network.
Simpler stacks such as those implementing Firewire and USB have appeared on custom chips at relatively low cost because these interfaces have become ubiquitously present in endpoint devices. However, the growth in speed of such chips has been relatively slow, the chips function more or less independently of one another, and when the chips are coupled in a device that uses both types of interfaces, performance noticeably degrades.
Offload capability for file system functions is not presently available, and requires both network offload and block storage offload to work, which cannot be achieved in a single-purpose network, TCP, or HBA card.
Programmable network interface cards such as the Alteon Tigon are known. Such programmable NICs typically have a fixed modest amount of shared memory and a small number of dedicated RISC processors performing DMA operations on the buffers. The firmware was designed to be replaceable, and may be regarded as programmable to a limited extent. These too, like offload cards, are relatively high cost and have not been widely adopted.
Recent trends in CPU chip design provide multiple CPU cores on the same die. The cores may share a common communications bus and main memory, but typically have separate caches. The use of shared memory allocation techniques that can draw memory from a large shared pool has been used in some data processing approaches but is not known for offload applications. Some approaches have used buffer pools at configuration time. Both multi-core CPUs and shared memory allocation techniques are now used on high-performance servers.
An issue associated with high-power servers is that the large amount of CPU power they provide may, in some cases, be under-utilized. Therefore, server users have begun deploying virtualization software that permits running multiple operating system instances on a single server. Virtualization software is commercially provided in Jaluna's OSware for Linux, VMWare, Microsoft's Virtual Server for multiple operating systems, IBM Hypervisor, and Xen. Xen is an open-source virtualization engine that currently includes support for some variants of Microsoft Windows, Linux, NetBSD, and FreeBSD. Virtualization software supports limited storage virtualization and can provide some networking functions such as virtual bridging. However, the use of virtualization does not reduce the complexity of managing a high-performance server in which the guest operating systems all independently implement complex I/O-networking functions. Nor does it escape performance and security concerns, which are being addressed directly with hardware support for virtualization including Intel's VT, Vanderpol, AMD's Pacifica, (VT), AMD's Pacifica and IBM's Hypervisor technologies.
Nevertheless, some network administrators are deploying general-purpose servers, with virtual bridging enabled, as edge network devices. When such servers are integrated into a packet-switched network that also includes traditional routers and switches, managing the servers and their bridging functions becomes challenging because such management typically requires using different management tools for the routers and switches as compared to the servers.
A further problem in the field involves operating system proliferation. Developers of networking client applications face a lack of control of the varying interfaces on some proprietary platforms that inhibits access to the full suite of features necessary to port clients. Further, developers face a large number of operating systems, each of which requires a different client, often with features that are not simple to port from one to another. This problem exists with Microsoft Windows, Linux, Solaris, AIX, HPUX, Mac OSX, Symbian, PalmOS, and other operating systems. In addition, some versions of applications or security policies may be specific to a particular version or patch level of an operating system. Current virtualized systems reimage the operating systems along with the network stacks, requiring subsequent configurations of the network interfaces every time a new and sometimes even a modified OS is needed.
Intel's ETA technology offloads network functions to a processor, but does not allow sharing the stack across hosts. Related literature in the field includes: A. Currid, “TCP Offload to the Rescue,” ACM Queue, http://acmqueue.com/modules.php?name=Content& pa=showpage&pid=154; Microsoft Corporation, “Microsoft Scaleable Networking Initiative,” http://www.microsoft.com/whdc/device/network/scale.mspx; and others.